查看原文
其他

【FIW2022 精彩回顾】方正富邦基于超融合构建核心数据库资源池的探索与实践

The following article is from FCC30+ Author 牟世强

精彩推荐


9 月 21—23 日,第一届“金融现代化 IT 基础架构转型论坛(FinTech Infrastructure Wave 2022)”成功举办。该论坛由中国信息通信研究院云计算与大数据研究所、《中国金融电脑》杂志社主办,北京志凌海纳科技有限公司(SmartX)与北京鲲鹏联合创新中心协办。论坛分为三大专场,覆盖银行、保险、证券、基金、期货、信托六大金融细分行业,内容涵盖多云平台建设、核心业务系统信创转型、超融合关键场景落地、核心业务 K8s 改造、数据中心零信任安全、基础设施即代码等前沿话题。


方正富邦基金管理有限公司基金运维经理牟世强发表了主题为“超融合构建核心数据库资源池”的演讲。


文丨方正富邦基金管理有限公司 牟世强

方正富邦基金管理有限公司(以下简称“方正富邦”)成立于 2011 年 6 月 30 日,是首家获证监会批准设立的两岸合资基金管理公司。
方正富邦的业务具有以下特点。一是方正富邦的公募基金产品主要包括权益类和固收类,也有一定量的专户产品,其中固收类产品的占比高于权益类产品,对接的用户主要是机构用户,直销柜台的用户相对较少,量级在千人左右。二是方正富邦官网客户端的使用度不是很高,OLAP 场景多于 OLTP 场景,系统后台任务的特性决定了 OLTP 中单笔事务处理的时间较长,对磁盘的吞吐要求很高。同时,业务场景并发低、虚拟环境下数据库 CPU 的开销低。
基于上述特征,通过超融合虚拟化技术可以满足大多数应用场景的需求。
一、传统 IT 基础架构部署挑战
方正富邦的传统 IT 基础架构主要分为核心生产资源池和一般生产资源池,核心生产资源池是由 4 台惠普的 DL580 服务器加上 EMC VNX 5600 混闪存储组成的 SAN 架构,承载的业务主要包括核心交易系统 O32、TA、估值等系统对应的数据库。
一般生产资源池是由 4 台惠普的 DL580 服务器加上 EMC VNX 5500 混闪存储组成的 SAN 架构,可支撑转码机、报盘机。办公环境主要运行在刀片服务器和 VNX 5500 上。
在资源池分开的情况下,数据库仍然面临着数据过于集中的问题,且存储系统常出现单点故障。此外,存储的使用率越来越高,容量和性能都无法满足业务发展。 
在此背景下,方正富邦 IT 基础架构转型以实际需求为出发点,采用成熟先进的技术设备去建设实用、稳健、可靠的技术架构环境,同时这套环境也要便于运维、易于扩展。

二、超融合部署演进过程
方正富邦自 2017 年起开始接触并了解超融合技术,2018 年采购了 5 个节点构建一般业务资源池,主要运行一些轻量应用,如报盘、转码机及交易所网关等应用;2019 年采购了 4 个节点用于构建办公业务资源池,该资源池承载了 90% 以上的办公类应用;2020 年再次采购了 4 个节点用于搭建数据库的专用资源池,并在其上运行了 8 套以上的数据库集群,其中包括估值、风控、监管报送、基金数据中心(CC)、直销等系统。
2021 年,一般资源池的角色定位得到加强,增加了容灾加固的属性,其容灾架构如图 1 所示。方正富邦的核心生产资源依然运行在集中存储上,其中,数据库是通过数据库的同步技术在容灾资源池上构建实时副本,再通过异步复制,在深证通行业云上构建异步副本。

图 1 方正富邦资源池容灾架构


同时,方正富邦在 2020 年新构建的数据库资源池上也采用相同方式,在容灾资源池上构建了实时副本,在深证通行业云上构建异步副本。
未来,方正富邦计划将核心系统跑在超融合上,传统的三层架构环境将作为容灾资源池。为此,方正富邦针对超融合在关键业务数据库上的性能进行了验证。
三、关键业务数据库跑批性能验证
方正富邦数据中心的数据量大概有 2.4TB,已经超过了超融合单节点的 SSD 缓存容量,后台执行跑批任务时,有时会发生击穿的情况,导致任务完成超时,进而影响系统处理。

CC 系统的主要作用是集中处理分析来自多个业务系统(如直销、估值、TA 等)的数据,用以满足业务部门使用和分析挖掘数据的需要,如市场营销、客户管理、运营支撑、报表报告、投研策略等。本次性能验证以 CC 作为测试数据库,主要是为了测试在高速闪存,即 NVMe 介质的配置下超融合的性能表现,同时也为后续核心业务系统(如 O32、TA 等)在技术架构选型上提供一些参考。
本次测试方法主要是比较 NVMe SSD 的配置和传统的 SATA SSD 混闪下超融合的性能,测试用例是方正富邦的数据中心系统,同时把近两个月的历史数据导入测试环境,每天模拟,手动触发后台任务,和生产上跑出来的时间进行比较。测试环境的配置为 48 Cores、256GB 内存加上 3.2TB 的全闪(如图 2 所示)。

图 2 测试环境配置


测试拓扑图由三个节点组成,后端网络是 25GbE,生产的服务器配置在计算资源上,比如 6326 的 CPU 、512GB 的单节点内存,都高于测试环境,唯一的差别就是生产环境使用的是 SSD 缓存加上机械盘的存储。
由于是测试服务器,使用的测试机缓存容量有限,单节点为 3.2TB,总容量大概为 9.6TB,再去除副本,可用容量为 4TB 左右。
从任务跑批验证数据对比(如图 3 所示)可以看出,在单任务跑批验证上,CC、估值数据落地,测试环境最快达到了 5 分 21 秒,而生产环境最快是 37 分钟。在多任务跑批验证上,测试环境每项任务的用时都优于生产环境,且测试环境的总用时为 31 分 42 秒,生产环境的总用时是 176 分钟。单任务跑批和多任务跑批的执行时间差距如此之大,可能是在混闪配置下,任务并行使得机械盘 I/O 被占满,导致任务出现暂停状态,后面的顺序任务也就无法执行了。

图 3 任务跑批验证数据对比


从 CPU 的负载监控数据(如图 4 所示)可以看出,CPU 的使用率在部分时段存在 70%、50%、30%、20% 等持续时间的连续负载压力,非常符合跑批场景下的特点,CPU 等待部分时段占比较高,通常情况下在 I/O 密集型的应用等待占比会高一些,对应存储负载的监控也能佐证这一点。

图 4 CPU 的负载监控数据


从存储负载监控数据(如图 5 所示)可以看出,峰值大概在 1.5GB/s,此时会出现持续读取压力,其余时间存在多次较高的突发访问量。结合之前 CPU 监控数据使用率和等待占比来看,存储性能就是跑批场景下最关键的性能影响因素。

图 5 存储负载监控数据


最终测试结论是:得益于超融合架构、NVMe 高速硬件介质、后端 25GbE 的高速网络等因素,以及超融合 I/O 本地化特性优化了存储读写性能,测试结果相比于当前的生产环境有较为明显的提升。
本次的测试结果为后续 TA、O32 等核心业务系统迁移到超融合环境中提供了参考依据。测试期间,超融合存储空间使用率达到 96%,多次测试的结果之间性能差异在秒级,可以看到,SmartX 超融合架构在高负载场景下依然可以保持着可靠稳定的性能输出。


四、经验分享


在使用超融合构建核心数据库资源池的过程中,方正富邦总结了以下经验以及注意事项。

一是相比于集中存储,超融合对前期的规划要求更高,需要明确业务场景、集群的使用性质,避免因虚拟机体量太大、存储资源不足造成计算资源浪费,或者出现密集型的应用对计算资源要求高导致前期配置性能不足的情况。
二是在虚拟环境下,通过克隆方式打造数据库操作系统基础环境,可以大量节约平时环境搭建的时间。


三是数据库的基础资源、CPU 及内存可以伴随虚拟机的特性随时调整。传统“物理机 + 存储”的采购方式,在开始采购硬件时,需要留出很多可扩展的空间,容易造成前期投入资源的浪费。
四是超融合部署简单,可以在很大程度上缩短业务上线时间。在实际的生产环境中,不考虑商务因素,从到货、搭建再到实时上线,有时能在一天时间内完成这些工作。
五是虚拟化主机维护时需要数据库关机,因为基于多写入器的核心数据库不支持在线 vMotion,所以维护主机时,跑在上面的数据库服务器需要关机重启。


推荐阅读:
继续滑动看下一个
志凌海纳SmartX
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存